Hi Jack,
Use toward the beginning of the main() function:
SetBitDirection(44,1);
Regards TK
| Group: DynoMotion |
Message: 9831 |
From: Russ Larson |
Date: 7/22/2014 |
| Subject: Re: Router On/Off |
You also need to add the code to set this as an output IO. They all default to inputs so put this code in your C routine. SetBitDirection44=1; this turns it to an output SetBit(44); This turns the output on to a one
ClearBit(44,1); This turn the output off, back to a zero Russ SetBitDirection<N>=<M> Description Defines the direction of an I/O bit to be an input or output. See also Digital I/O Screen. Parameters <N> Bit number to assign. Valid range 0...30 <M> Direction 0 = input, 1 = output Example SetBitDirection0=1 From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, July 22, 2014 2:55 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Router On/Off Tom,
I recently added a small relay board to my CNC router so I could use the G code program to turn my router on and off. I use M3 to set bit 44 to 0 and M5 set bit 44 to 1 and then connected the relay board through pin 5. It work fine except that every time I cycle power I have to go into the digital I/O screen and set bit 44 as an output. I tried adding a line or 2 to my init program but not knowing anything about C it didn't work.
Here's what I tried:
int main()
{
void SetBit(44);
void SetStateBit(44,1); ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
I don't need to control speed just yet, just turn the router on. How do I set an I/O as an output? Do I need to add something to the Init program or is there an easier way? If I need to add something to the Init file what is the correct syntax and where does it go in the program?
Jack |
|
| Group: DynoMotion |
Message: 9835 |
From: Jack Gizienski |
Date: 7/22/2014 |
| Subject: Re: Router On/Off |
Russ, For some reason it didn’t like SetBitDirection44=1, I got a compiler error – SetBitDirection undeclared. However, changing it to Tom’s suggestion of SetBitDirection(44,1) worked fine. I saw in the documentation that your syntax appeared to be correct but my compiler didn’t agree. Why would that be? I’m running 432. From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, July 22, 2014 3:33 PM
To: DynoMotion@yahoogroups.com
Subject: RE: [DynoMotion] Router On/Off You also need to add the code to set this as an output IO. They all default to inputs so put this code in your C routine. SetBitDirection44=1; this turns it to an output SetBit(44); This turns the output on to a one
ClearBit(44,1); This turn the output off, back to a zero Russ SetBitDirection<N>=<M> Description Defines the direction of an I/O bit to be an input or output. See also Digital I/O Screen. Parameters <N> Bit number to assign. Valid range 0...30 <M> Direction 0 = input, 1 = output Example SetBitDirection0=1 From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, July 22, 2014 2:55 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Router On/Off Tom,
I recently added a small relay board to my CNC router so I could use the G code program to turn my router on and off. I use M3 to set bit 44 to 0 and M5 set bit 44 to 1 and then connected the relay board through pin 5. It work fine except that every time I cycle power I have to go into the digital I/O screen and set bit 44 as an output. I tried adding a line or 2 to my init program but not knowing anything about C it didn't work.
Here's what I tried:
int main()
{
void SetBit(44);
void SetStateBit(44,1); ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
I don't need to control speed just yet, just turn the router on. How do I set an I/O as an output? Do I need to add something to the Init program or is there an easier way? If I need to add something to the Init file what is the correct syntax and where does it go in the program?
Jack |
|
| Group: DynoMotion |
Message: 9836 |
From: Jack Gizienski |
Date: 7/22/2014 |
| Subject: Re: Router On/Off |
Tom, That did the trick. I also added Russ’s suggestion of SetBit(44) to make sure to router is off. However, I now have another problem. When I do a power cycle my relay board turns on while the 2 green lights are flashing on the Kflop . This could be a dangerous situation if the router starts up on it’s own. Is there a way to keep bit 44 from turning on before I’m ready? From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, July 22, 2014 3:02 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off Use toward the beginning of the main() function:
From: "jackgiz@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, July 22, 2014 11:55 AM
Subject: [DynoMotion] Router On/Off Tom,
I recently added a small relay board to my CNC router so I could use the G code program to turn my router on and off. I use M3 to set bit 44 to 0 and M5 set bit 44 to 1 and then connected the relay board through pin 5. It work fine except that every time I cycle power I have to go into the digital I/O screen and set bit 44 as an output. I tried adding a line or 2 to my init program but not knowing anything about C it didn't work.
Here's what I tried:
int main()
{
void SetBit(44);
void SetStateBit(44,1); ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
I don't need to control speed just yet, just turn the router on. How do I set an I/O as an output? Do I need to add something to the Init program or is there an easier way? If I need to add something to the Init file what is the correct syntax and where does it go in the program?
Jack |
|
| Group: DynoMotion |
Message: 9837 |
From: Tom Kerekes |
Date: 7/22/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
Operations can be performed in KFLOP two different ways.
Strings of characters can be sent from the PC through USB to KFLOP as Script
commands. A Host program running on the PC can send these commands or you can just type them in the KMotion Console Screen to send them. The description you posted is for the SetBitDirection Script command.
Alternately a C Program can be executed within KFLOP to do things. From a C Program a function such as SetBitDirection() can be called with appropriate parameters. C Programs are more powerful than script functions. See the KMotionDef.h file for available C Function and C Variable definitions.
HTH Regards TK
| Group: DynoMotion |
Message: 9838 |
From: Tom Kerekes |
Date: 7/22/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
You will need to fix that in Hardware. Until KFLOP fully boots up the IO are configured as inputs which is basically like they are disconnected. If the relay signal needs to be driven high to keep the spindle off then you will need to do something like add a pull up resistor to make this be the case until KFLOP gains control.
It is sort of odd that whatever relay board needs to be driven high to turn off. Do you have a specification for it?
Regards TK
| Group: DynoMotion |
Message: 9839 |
From: Jack Gizienski |
Date: 7/22/2014 |
| Subject: Re: Router On/Off [3 Attachments] |
Thanks for your quick response Tom. You are a very patient man. Here’s some info on the relay board. http://www.ebay.com/itm/5V-2-Channel-Relay-Module-Expansion-Board-for-Arduino-PIC-ARM-DSP-/321470070627?pt=LH_DefaultDomain_0&hash=item4ad91bff63 I am currently going from the Kflop to a breakout board and then to this relay board. I could probably go directly to the relay board since it’s opto isolated but didn’t want to risk damaging the Kflop. I checked the input voltage on the relay board and it is truly 5 Volts in the off position. I thought this was strange also. The little yellow jumper doesn’t seem to do much whether it there or not. I added a 1k pull up resistor between the breakout board and the relay board without any success. What size pull up can I add to the Kflop JP7 pin 5? I think I read somewhere that those outputs can only drive 10 ma. Is 1k ok? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, July 22, 2014 9:13 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [3 Attachments] [Attachment(s) from Tom Kerekes included below] You will need to fix that in Hardware. Until KFLOP fully boots up the IO are configured as inputs which is basically like they are disconnected. If the relay signal needs to be driven high to keep the spindle off then you will need to do something like add a pull up resistor to make this be the case until KFLOP gains control. It is sort of odd that whatever relay board needs to be driven high to turn off. Do you have a specification for it? That did the trick. I also added Russ’s suggestion of SetBit(44) to make sure to router is off. However, I now have another problem. When I do a power cycle my relay board turns on while the 2 green lights are flashing on the Kflop . This could be a dangerous situation if the router starts up on it’s own. Is there a way to keep bit 44 from turning on before I’m ready? Use toward the beginning of the main() function: Tom,
I recently added a small relay board to my CNC router so I could use the G code program to turn my router on and off. I use M3 to set bit 44 to 0 and M5 set bit 44 to 1 and then connected the relay board through pin 5. It work fine except that every time I cycle power I have to go into the digital I/O screen and set bit 44 as an output. I tried adding a line or 2 to my init program but not knowing anything about C it didn't work.
Here's what I tried:
int main()
{
void SetBit(44);
void SetStateBit(44,1); ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
I don't need to control speed just yet, just turn the router on. How do I set an I/O as an output? Do I need to add something to the Init program or is there an easier way? If I need to add something to the Init file what is the correct syntax and where does it go in the program?
Jack   
|
|
| Group: DynoMotion |
Message: 9840 |
From: Tom Kerekes |
Date: 7/22/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
I don't know how you wired the connections to the spindle. But it looks like those relays have a normally open and normally closed set of contacts. When the coil is energized the normally open side closes and the normally closed side opens. If you change to the opposite side then the spindle may stay off until activated by KFLOP's output.
Google Relays Normally open and normally closed. Also "Single-pole double-throw" relays.
Regards TK
| Group: DynoMotion |
Message: 9851 |
From: Jack Gizienski |
Date: 7/23/2014 |
| Subject: Re: Router On/Off [3 Attachments] |
Tom, Not sure that changing the sex of everything will solve the problem. If I use the NC contacts the router will start immediately (although very briefly) as soon as I turn on power. I see 3 possible solutions, a pull up on pin 5, a timer circuit that won’t allow the pin 5 signal to pass for 5 or 10 seconds as the Kflop comes up, or add a second switch to activate the router power after waiting for the 2 green lights to come on. Number 3 seems like the easiest solution. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, July 22, 2014 11:37 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [3 Attachments] [Attachment(s) from Tom Kerekes included below] I don't know how you wired the connections to the spindle. But it looks like those relays have a normally open and normally closed set of contacts. When the coil is energized the normally open side closes and the normally closed side opens. If you change to the opposite side then the spindle may stay off until activated by KFLOP's output. Google Relays Normally open and normally closed. Also "Single-pole double-throw" relays. Thanks for your quick response Tom. You are a very patient man. Here’s some info on the relay board. I am currently going from the Kflop to a breakout board and then to this relay board. I could probably go directly to the relay board since it’s opto isolated but didn’t want to risk damaging the Kflop. I checked the input voltage on the relay board and it is truly 5 Volts in the off position. I thought this was strange also. The little yellow jumper doesn’t seem to do much whether it there or not. I added a 1k pull up resistor between the breakout board and the relay board without any success. What size pull up can I add to the Kflop JP7 pin 5? I think I read somewhere that those outputs can only drive 10 ma. Is 1k ok? You will need to fix that in Hardware. Until KFLOP fully boots up the IO are configured as inputs which is basically like they are disconnected. If the relay signal needs to be driven high to keep the spindle off then you will need to do something like add a pull up resistor to make this be the case until KFLOP gains control. It is sort of odd that whatever relay board needs to be driven high to turn off. Do you have a specification for it? That did the trick. I also added Russ’s suggestion of SetBit(44) to make sure to router is off. However, I now have another problem. When I do a power cycle my relay board turns on while the 2 green lights are flashing on the Kflop . This could be a dangerous situation if the router starts up on it’s own. Is there a way to keep bit 44 from turning on before I’m ready? Use toward the beginning of the main() function: Tom,
I recently added a small relay board to my CNC router so I could use the G code program to turn my router on and off. I use M3 to set bit 44 to 0 and M5 set bit 44 to 1 and then connected the relay board through pin 5. It work fine except that every time I cycle power I have to go into the digital I/O screen and set bit 44 as an output. I tried adding a line or 2 to my init program but not knowing anything about C it didn't work.
Here's what I tried:
int main()
{
void SetBit(44);
void SetStateBit(44,1); ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
I don't need to control speed just yet, just turn the router on. How do I set an I/O as an output? Do I need to add something to the Init program or is there an easier way? If I need to add something to the Init file what is the correct syntax and where does it go in the program?
Jack |
|
| Group: DynoMotion |
Message: 9924 |
From: Jack Gizienski |
Date: 8/6/2014 |
| Subject: Re: Router On/Off [3 Attachments] |
Tom, 2 questions: I decided to use a 1k pull up resistor between pin 1 of JP7 (3.3volts) and pin 5 to keep the pin pulled high during Kflop initialization at power up. It works perfectly but I want to make sure that I won’t damage the Kflop. Do you see a problem with this solution? Do you know of any guide for calibration an Axis and then adding backlash compensation? I feel like I’m running in circles playing with counts/inch and backlash. I’m cutting 2 concentric circles cut in opposite directions and measuring the distance between the two. Is there a simple cookbook approach? Jack From: Jack Gizienski [mailto:jackgiz@...]
Sent: Wednesday, July 23, 2014 10:24 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [3 Attachments] Tom, Not sure that changing the sex of everything will solve the problem. If I use the NC contacts the router will start immediately (although very briefly) as soon as I turn on power. I see 3 possible solutions, a pull up on pin 5, a timer circuit that won’t allow the pin 5 signal to pass for 5 or 10 seconds as the Kflop comes up, or add a second switch to activate the router power after waiting for the 2 green lights to come on. Number 3 seems like the easiest solution. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, July 22, 2014 11:37 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [3 Attachments] [Attachment(s) from Tom Kerekes included below] I don't know how you wired the connections to the spindle. But it looks like those relays have a normally open and normally closed set of contacts. When the coil is energized the normally open side closes and the normally closed side opens. If you change to the opposite side then the spindle may stay off until activated by KFLOP's output. Google Relays Normally open and normally closed. Also "Single-pole double-throw" relays. Thanks for your quick response Tom. You are a very patient man. Here’s some info on the relay board. I am currently going from the Kflop to a breakout board and then to this relay board. I could probably go directly to the relay board since it’s opto isolated but didn’t want to risk damaging the Kflop. I checked the input voltage on the relay board and it is truly 5 Volts in the off position. I thought this was strange also. The little yellow jumper doesn’t seem to do much whether it there or not. I added a 1k pull up resistor between the breakout board and the relay board without any success. What size pull up can I add to the Kflop JP7 pin 5? I think I read somewhere that those outputs can only drive 10 ma. Is 1k ok? You will need to fix that in Hardware. Until KFLOP fully boots up the IO are configured as inputs which is basically like they are disconnected. If the relay signal needs to be driven high to keep the spindle off then you will need to do something like add a pull up resistor to make this be the case until KFLOP gains control. It is sort of odd that whatever relay board needs to be driven high to turn off. Do you have a specification for it? That did the trick. I also added Russ’s suggestion of SetBit(44) to make sure to router is off. However, I now have another problem. When I do a power cycle my relay board turns on while the 2 green lights are flashing on the Kflop . This could be a dangerous situation if the router starts up on it’s own. Is there a way to keep bit 44 from turning on before I’m ready? Use toward the beginning of the main() function: Tom,
I recently added a small relay board to my CNC router so I could use the G code program to turn my router on and off. I use M3 to set bit 44 to 0 and M5 set bit 44 to 1 and then connected the relay board through pin 5. It work fine except that every time I cycle power I have to go into the digital I/O screen and set bit 44 as an output. I tried adding a line or 2 to my init program but not knowing anything about C it didn't work.
Here's what I tried:
int main()
{
void SetBit(44);
void SetStateBit(44,1); ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
I don't need to control speed just yet, just turn the router on. How do I set an I/O as an output? Do I need to add something to the Init program or is there an easier way? If I need to add something to the Init file what is the correct syntax and where does it go in the program?
Jack |
|
| Group: DynoMotion |
Message: 9928 |
From: Tom Kerekes |
Date: 8/7/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
The 1Kohm pull up to 3.3V should not be a problem.
With regard to "calibration" do you mean finding the correct scale factor? The normal way
to adjust scale is to make a small move (to set the backlash direction) then make a large in the same direction and measure the distance actually moved. Use the ratio of the commanded to the measured distances as a correction factor.
With regard to backlash: I don't really understand what information concentric circles would provide. One method is to move to one commanded position from both directions and measure the difference in the actual position.
Regards TK
| Group: DynoMotion |
Message: 9953 |
From: Jack Gizienski |
Date: 8/12/2014 |
| Subject: Re: Router On/Off [7 Attachments] |
Tom, I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: #include "KMotionDef.h" // Defines axis 0 and 1 as simple steppers // enables them // sets them as an xy coordinate system for GCode int main() { //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->Vel=10000; ch0->Accel=80000; ch0->Jerk=800000; ch0->P=0; ch0->I=0.01; ch0->D=0; ch0->FFAccel=0; ch0->FFVel=0; ch0->MaxI=200; ch0->MaxErr=1e+006; ch0->MaxOutput=200; ch0->DeadBandGain=1; ch0->DeadBandRange=0; ch0->OutputChan0=0; ch0->OutputChan1=0; ch0->MasterAxis=-1; ch0->LimitSwitchOptions=0x0; ch0->OutputGain=1; ch0->OutputOffset=1; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->BacklashRate=400; ch0->invDistPerCycle=1; ch0->Lead=0; ch0->MaxFollowingError=1000000000; //ch0->StepperAmplitude=30; EnableAxisDest(0,0); ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE; ch1->Vel=13000; ch1->Accel=50000; ch1->Jerk=800000; //ch1->P=0; //ch1->I=0.01; //ch1->D=0; //ch1->FFAccel=0; //ch1->FFVel=0; //ch1->MaxI=200; //ch1->MaxErr=1e+006; //ch1->MaxOutput=200; //ch1->DeadBandGain=1; //ch1->DeadBandRange=0; ch1->OutputChan0=0; ch1->OutputChan1=0; ch1->MasterAxis=-1; ch1->LimitSwitchOptions=0x0; //ch1->OutputGain=1; //ch1->OutputOffset=1; //ch1->BacklashMode= BACKLASH_OFF; //ch1->BacklashAmount=18.5; //ch1->BacklashRate=500; //ch1->invDistPerCycle=1; //ch1->Lead=0; //ch1->MaxFollowingError=1000000000; //ch1->StepperAmplitude=30; EnableAxisDest(1,0); ch2->InputMode=NO_INPUT_MODE; ch2->OutputMode=STEP_DIR_MODE; ch2->Vel=8000; ch2->Accel=30000; ch2->Jerk=300000; ch2->P=0; ch2->I=0.01; ch2->D=0; ch2->FFAccel=0; ch2->FFVel=0; ch2->MaxI=200; ch2->MaxErr=1e+006; ch2->MaxOutput=200; ch2->DeadBandGain=1; ch2->DeadBandRange=0; ch2->OutputChan0=0; ch2->OutputChan1=0; ch2->MasterAxis=-1; ch2->LimitSwitchOptions=0x0; ch2->OutputGain=1; ch2->OutputOffset=1; ch2->BacklashMode=BACKLASH_OFF; ch2->BacklashAmount=36; ch2->BacklashRate=700; ch2->invDistPerCycle=1; ch2->Lead=10; ch2->MaxFollowingError=1000000000; //ch2->StepperAmplitude=30; EnableAxisDest(2,0); DefineCoordSystem(0,1,2,-1); return 0; } Any suggestions? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, August 07, 2014 8:55 AM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [7 Attachments] [Attachment(s) from Tom Kerekes included below] The 1Kohm pull up to 3.3V should not be a problem. With regard to "calibration" do you mean finding the correct scale factor? The normal way to adjust scale is to make a small move (to set the backlash direction) then make a large in the same direction and measure the distance actually moved. Use the ratio of the commanded to the measured distances as a correction factor. With regard to backlash: I don't really understand what information concentric circles would provide. One method is to move to one commanded position from both directions and measure the difference in the actual position. I decided to use a 1k pull up resistor between pin 1 of JP7 (3.3volts) and pin 5 to keep the pin pulled high during Kflop initialization at power up. It works perfectly but I want to make sure that I won’t damage the Kflop. Do you see a problem with this solution? Do you know of any guide for calibration an Axis and then adding backlash compensation? I feel like I’m running in circles playing with counts/inch and backlash. I’m cutting 2 concentric circles cut in opposite directions and measuring the distance between the two. Is there a simple cookbook approach? From: Jack Gizienski [mailto:jackgiz@...]
Sent: Wednesday, July 23, 2014 10:24 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [3 Attachments] Not sure that changing the sex of everything will solve the problem. If I use the NC contacts the router will start immediately (although very briefly) as soon as I turn on power. I see 3 possible solutions, a pull up on pin 5, a timer circuit that won’t allow the pin 5 signal to pass for 5 or 10 seconds as the Kflop comes up, or add a second switch to activate the router power after waiting for the 2 green lights to come on. Number 3 seems like the easiest solution. I don't know how you wired the connections to the spindle. But it looks like those relays have a normally open and normally closed set of contacts. When the coil is energized the normally open side closes and the normally closed side opens. If you change to the opposite side then the spindle may stay off until activated by KFLOP's output. Google Relays Normally open and normally closed. Also "Single-pole double-throw" relays. Thanks for your quick response Tom. You are a very patient man. Here’s some info on the relay board. I am currently going from the Kflop to a breakout board and then to this relay board. I could probably go directly to the relay board since it’s opto isolated but didn’t want to risk damaging the Kflop. I checked the input voltage on the relay board and it is truly 5 Volts in the off position. I thought this was strange also. The little yellow jumper doesn’t seem to do much whether it there or not. I added a 1k pull up resistor between the breakout board and the relay board without any success. What size pull up can I add to the Kflop JP7 pin 5? I think I read somewhere that those outputs can only drive 10 ma. Is 1k ok? You will need to fix that in Hardware. Until KFLOP fully boots up the IO are configured as inputs which is basically like they are disconnected. If the relay signal needs to be driven high to keep the spindle off then you will need to do something like add a pull up resistor to make this be the case until KFLOP gains control. It is sort of odd that whatever relay board needs to be driven high to turn off. Do you have a specification for it? That did the trick. I also added Russ’s suggestion of SetBit(44) to make sure to router is off. However, I now have another problem. When I do a power cycle my relay board turns on while the 2 green lights are flashing on the Kflop . This could be a dangerous situation if the router starts up on it’s own. Is there a way to keep bit 44 from turning on before I’m ready? Use toward the beginning of the main() function: Tom,
I recently added a small relay board to my CNC router so I could use the G code program to turn my router on and off. I use M3 to set bit 44 to 0 and M5 set bit 44 to 1 and then connected the relay board through pin 5. It work fine except that every time I cycle power I have to go into the digital I/O screen and set bit 44 as an output. I tried adding a line or 2 to my init program but not knowing anything about C it didn't work.
Here's what I tried:
int main()
{
void SetBit(44);
void SetStateBit(44,1); ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
I don't need to control speed just yet, just turn the router on. How do I set an I/O as an output? Do I need to add something to the Init program or is there an easier way? If I need to add something to the Init file what is the correct syntax and where does it go in the program?
Jack    
|
|
| Group: DynoMotion |
Message: 9955 |
From: Tom Kerekes |
Date: 8/12/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
I don't recall that you specified what type of Drives you have or what their timing specs are. But
a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing.
KFLOP only changes the direction 0.25us
before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with:
FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us
Also try inverting the pulse by setting bit 7 with
FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert
Please see if incuding one of those in your Init C Program solves your problem
Regards TK
From: "'Jack Gizienski' jackgiz@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, August
12, 2014 11:34 AM
Subject: RE: [DynoMotion] Router On/Off
Tom, I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems
to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: #include "KMotionDef.h" // Defines axis 0 and 1 as simple steppers // enables them // sets them as an xy coordinate system for GCode int main() { //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->Vel=10000; ch0->Accel=80000;
ch0->Jerk=800000; ch0->P=0; ch0->I=0.01; ch0->D=0; ch0->FFAccel=0;
ch0->FFVel=0; ch0->MaxI=200; ch0->MaxErr=1e+006; ch0->MaxOutput=200; ch0->DeadBandGain=1; ch0->DeadBandRange=0; ch0->OutputChan0=0; ch0->OutputChan1=0; ch0->MasterAxis=-1; ch0->LimitSwitchOptions=0x0; ch0->OutputGain=1; ch0->OutputOffset=1; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->BacklashRate=400; ch0->invDistPerCycle=1; ch0->Lead=0; ch0->MaxFollowingError=1000000000;
//ch0->StepperAmplitude=30; EnableAxisDest(0,0); ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE;
ch1->Vel=13000; ch1->Accel=50000; ch1->Jerk=800000; //ch1->P=0; //ch1->I=0.01; //ch1->D=0; //ch1->FFAccel=0; //ch1->FFVel=0; //ch1->MaxI=200; //ch1->MaxErr=1e+006; //ch1->MaxOutput=200; //ch1->DeadBandGain=1; //ch1->DeadBandRange=0; ch1->OutputChan0=0;
ch1->OutputChan1=0; ch1->MasterAxis=-1; ch1->LimitSwitchOptions=0x0; //ch1->OutputGain=1; //ch1->OutputOffset=1; //ch1->BacklashMode= BACKLASH_OFF; //ch1->BacklashAmount=18.5; //ch1->BacklashRate=500; //ch1->invDistPerCycle=1;
//ch1->Lead=0; //ch1->MaxFollowingError=1000000000; //ch1->StepperAmplitude=30; EnableAxisDest(1,0);
ch2->InputMode=NO_INPUT_MODE; ch2->OutputMode=STEP_DIR_MODE; ch2->Vel=8000; ch2->Accel=30000; ch2->Jerk=300000; ch2->P=0; ch2->I=0.01; ch2->D=0; ch2->FFAccel=0; ch2->FFVel=0; ch2->MaxI=200; ch2->MaxErr=1e+006; ch2->MaxOutput=200; ch2->DeadBandGain=1; ch2->DeadBandRange=0; ch2->OutputChan0=0; ch2->OutputChan1=0; ch2->MasterAxis=-1; ch2->LimitSwitchOptions=0x0;
ch2->OutputGain=1; ch2->OutputOffset=1; ch2->BacklashMode=BACKLASH_OFF; ch2->BacklashAmount=36; ch2->BacklashRate=700; ch2->invDistPerCycle=1; ch2->Lead=10; ch2->MaxFollowingError=1000000000; //ch2->StepperAmplitude=30; EnableAxisDest(2,0); DefineCoordSystem(0,1,2,-1); return 0; } Any suggestions? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, August 07, 2014 8:55 AM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [7 Attachments]
The 1Kohm pull up to 3.3V should not be a
problem. With regard to "calibration" do you mean finding the correct scale factor? The normal way to adjust scale is to make a small move (to set the backlash direction) then make a large in the same direction and measure the distance actually moved. Use the ratio of the commanded to the measured distances as a correction factor. With regard to backlash: I don't really understand what information concentric circles would provide. One method is to move to one
commanded position from both directions and measure the difference in the actual position. I decided to use a 1k
pull up resistor between pin 1 of JP7 (3.3volts) and pin 5 to keep the pin pulled high during Kflop initialization at power up. It works perfectly but I want to make sure that I won’t damage the Kflop. Do you see a problem with this solution? Do you know of any guide for calibration an Axis and then adding backlash compensation? I feel like I’m running in circles playing with counts/inch and backlash. I’m cutting 2 concentric circles cut in opposite directions and measuring the distance between the two. Is there a simple cookbook approach? From: Jack Gizienski [mailto:jackgiz@...]
Sent: Wednesday, July 23, 2014 10:24 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [3 Attachments] Not sure that changing the sex of everything will solve the problem. If I use the NC contacts the router will start immediately (although very briefly) as soon as I turn on power. I see 3 possible solutions, a pull up on pin 5, a timer circuit that
won’t allow the pin 5 signal to pass for 5 or 10 seconds as the Kflop comes up, or add a second switch to activate the router power after waiting for the 2 green lights to come on. Number 3 seems like the easiest solution. I don't know how you wired the connections to the spindle. But it looks like those relays have a normally open and normally closed set of contacts. When the coil is energized the normally open side closes and the normally closed side opens. If you change to the opposite side then the spindle may stay off until activated by KFLOP's output. Google Relays
Normally open and normally closed. Also "Single-pole double-throw" relays. Thanks for your quick response Tom. You are a very patient man. Here’s some info on the relay board. I am currently going from the Kflop to a breakout board and then to this relay board. I could probably go directly to the relay board since it’s opto isolated but didn’t want to risk damaging the Kflop. I checked the input voltage on the relay board and it is truly 5
Volts in the off position. I thought this was strange also. The little yellow jumper doesn’t seem to do much whether it there or not. I added a 1k pull up resistor between the breakout board and the relay board without any success. What size pull up can I add to the Kflop JP7 pin 5? I think I read somewhere that those outputs can only drive 10 ma. Is 1k ok? You will need to fix that in Hardware. Until KFLOP fully boots up the IO are configured as inputs which is basically like they are disconnected. If the relay signal needs to be driven high to keep the spindle off then you will need to do something like add a pull up resistor to make this be the case until KFLOP gains control. It is
sort of odd that whatever relay board needs to be driven high to turn off. Do you have a specification for it? That did the trick. I also added Russ’s suggestion of SetBit(44) to make sure to router is off. However, I now
have another problem. When I do a power cycle my relay board turns on while the 2 green lights are flashing on the Kflop . This could be a dangerous situation if the router starts up on it’s own. Is there a way to keep bit 44 from turning on before I’m ready? Use toward the beginning of the main() function: Tom,
I recently added a small relay board to my CNC router so I could use the G code program to turn my router on and off. I use M3 to set bit 44 to 0 and M5 set bit 44 to 1 and then connected the relay board through pin 5. It work fine except that every time I cycle power I have to go into the digital I/O screen and set bit 44 as an output. I tried adding a line or 2 to my init program but not knowing anything about C it didn't work.
Here's what I tried:
int main()
{
void
SetBit(44);
void SetStateBit(44,1); ch0->InputMode=NO_INPUT_MODE;
ch0->OutputMode=STEP_DIR_MODE;
I don't need to control speed just yet, just turn the router on. How do I set an I/O as an output? Do I need to add something to the Init program or is there an easier way? If I need to add something to the Init file what is the correct
syntax and where does it go in the program?
Jack  |
|
| Group: DynoMotion |
Message: 9979 |
From: Jack Gizienski |
Date: 8/15/2014 |
| Subject: Re: Router On/Off [6 Attachments] |
Hi Tom, I did try the FPGA command but it didn’t seem to make a difference. However, I did ultimately find the problem. I was using the BOB that came with my China Drivers and Steppers not realizing that the drivers had opto-isolated inputs. Below is the screen shot of the signal coming out of the BOB into the drivers. It’s amazing that they worked at all. Driving the Stepper Drivers directly from the Kflop provided a perfect digital signal and solved the losing/gaining steps problem I was having. Jack 
From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, August 12, 2014 6:43 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [6 Attachments] [Attachment(s) from Tom Kerekes included below] I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: // Defines axis 0 and 1 as simple steppers // sets them as an xy coordinate system for GCode //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->LimitSwitchOptions=0x0; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->MaxFollowingError=1000000000; //ch0->StepperAmplitude=30; ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE; ch1->LimitSwitchOptions=0x0; //ch1->BacklashMode= BACKLASH_OFF; //ch1->BacklashAmount=18.5; //ch1->invDistPerCycle=1; //ch1->MaxFollowingError=1000000000; //ch1->StepperAmplitude=30; ch2->InputMode=NO_INPUT_MODE; ch2->OutputMode=STEP_DIR_MODE; ch2->LimitSwitchOptions=0x0; ch2->BacklashMode=BACKLASH_OFF; ch2->MaxFollowingError=1000000000; //ch2->StepperAmplitude=30; DefineCoordSystem(0,1,2,-1); The 1Kohm pull up to 3.3V should not be a problem. With regard to "calibration" do you mean finding the correct scale factor? The normal way to adjust scale is to make a small move (to set the backlash direction) then make a large in the same direction and measure the distance actually moved. Use the ratio of the commanded to the measured distances as a correction factor. With regard to backlash: I don't really understand what information concentric circles would provide. One method is to move to one commanded position from both directions and measure the difference in the actual position. I decided to use a 1k pull up resistor between pin 1 of JP7 (3.3volts) and pin 5 to keep the pin pulled high during Kflop initialization at power up. It works perfectly but I want to make sure that I won’t damage the Kflop. Do you see a problem with this solution? Do you know of any guide for calibration an Axis and then adding backlash compensation? I feel like I’m running in circles playing with counts/inch and backlash. I’m cutting 2 concentric circles cut in opposite directions and measuring the distance between the two. Is there a simple cookbook approach? From: Jack Gizienski [mailto:jackgiz@...]
Sent: Wednesday, July 23, 2014 10:24 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [3 Attachments] Not sure that changing the sex of everything will solve the problem. If I use the NC contacts the router will start immediately (although very briefly) as soon as I turn on power. I see 3 possible solutions, a pull up on pin 5, a timer circuit that won’t allow the pin 5 signal to pass for 5 or 10 seconds as the Kflop comes up, or add a second switch to activate the router power after waiting for the 2 green lights to come on. Number 3 seems like the easiest solution. |
|
| Group: DynoMotion |
Message: 10023 |
From: Jack Gizienski |
Date: 8/24/2014 |
| Subject: Re: Router On/Off [6 Attachments] |
Tom, I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, August 12, 2014 6:43 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [6 Attachments] [Attachment(s) from Tom Kerekes included below] I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: // Defines axis 0 and 1 as simple steppers // sets them as an xy coordinate system for GCode //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->LimitSwitchOptions=0x0; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->MaxFollowingError=1000000000; //ch0->StepperAmplitude=30; ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE; ch1->LimitSwitchOptions=0x0; //ch1->BacklashMode= BACKLASH_OFF; //ch1->BacklashAmount=18.5; //ch1->invDistPerCycle=1; //ch1->MaxFollowingError=1000000000; //ch1->StepperAmplitude=30; ch2->InputMode=NO_INPUT_MODE; ch2->OutputMode=STEP_DIR_MODE; ch2->LimitSwitchOptions=0x0; ch2->BacklashMode=BACKLASH_OFF; ch2->MaxFollowingError=1000000000; //ch2->StepperAmplitude=30; DefineCoordSystem(0,1,2,-1); The 1Kohm pull up to 3.3V should not be a problem. With regard to "calibration" do you mean finding the correct scale factor? The normal way to adjust scale is to make a small move (to set the backlash direction) then make a large in the same direction and measure the distance actually moved. Use the ratio of the commanded to the measured distances as a correction factor. With regard to backlash: I don't really understand what information concentric circles would provide. One method is to move to one commanded position from both directions and measure the difference in the actual position. I decided to use a 1k pull up resistor between pin 1 of JP7 (3.3volts) and pin 5 to keep the pin pulled high during Kflop initialization at power up. It works perfectly but I want to make sure that I won’t damage the Kflop. Do you see a problem with this solution? Do you know of any guide for calibration an Axis and then adding backlash compensation? I feel like I’m running in circles playing with counts/inch and backlash. I’m cutting 2 concentric circles cut in opposite directions and measuring the distance between the two. Is there a simple cookbook approach? From: Jack Gizienski [mailto:jackgiz@...]
Sent: Wednesday, July 23, 2014 10:24 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [3 Attachments] Not sure that changing the sex of everything will solve the problem. If I use the NC contacts the router will start immediately (although very briefly) as soon as I turn on power. I see 3 possible solutions, a pull up on pin 5, a timer circuit that won’t allow the pin 5 signal to pass for 5 or 10 seconds as the Kflop comes up, or add a second switch to activate the router power after waiting for the 2 green lights to come on. Number 3 seems like the easiest solution. |
|
| Group: DynoMotion |
Message: 10025 |
From: Tom Kerekes |
Date: 8/24/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there.
HTH Regards TK
| Group: DynoMotion |
Message: 10039 |
From: Jack Gizienski |
Date: 8/26/2014 |
| Subject: Re: Router On/Off [6 Attachments] |
Tom, I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Sunday, August 24, 2014 12:40 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [6 Attachments] [Attachment(s) from Tom Kerekes included below] Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: // Defines axis 0 and 1 as simple steppers // sets them as an xy coordinate system for GCode //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->LimitSwitchOptions=0x0; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->MaxFollowingError=1000000000; //ch0->StepperAmplitude=30; ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE; ch1->LimitSwitchOptions=0x0; //ch1->BacklashMode= BACKLASH_OFF; //ch1->BacklashAmount=18.5; //ch1->invDistPerCycle=1; //ch1->MaxFollowingError=1000000000; //ch1->StepperAmplitude=30; ch2->InputMode=NO_INPUT_MODE; ch2->OutputMode=STEP_DIR_MODE; ch2->LimitSwitchOptions=0x0; ch2->BacklashMode=BACKLASH_OFF; ch2->MaxFollowingError=1000000000; //ch2->StepperAmplitude=30; DefineCoordSystem(0,1,2,-1); Jack
(Message over 64 KB, truncated) |
|
| Group: DynoMotion |
Message: 10040 |
From: Tom Kerekes |
Date: 8/26/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See:
Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state.
Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one.
The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero.
HTH Regards TK
From: "'Jack Gizienski' jackgiz@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, August 26, 2014 4:16 PM
Subject: RE: [DynoMotion] Router On/Off
Tom, I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1,
// limit bit number to watch for 1, // limit polarity to wait for (1 or 0)
100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1
for none) 0, // index polarity to wait for (1 or 0) 1000);
// amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Sunday, August 24, 2014 12:40 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [6 Attachments] Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10
times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: // Defines axis 0 and 1 as simple steppers // sets them as an xy coordinate system for GCode //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->LimitSwitchOptions=0x0; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->MaxFollowingError=1000000000; //ch0->StepperAmplitude=30; ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE; ch1->LimitSwitchOptions=0x0; //ch1->BacklashMode= BACKLASH_OFF; //ch1->BacklashAmount=18.5; //ch1->invDistPerCycle=1; //ch1->MaxFollowingError=1000000000; //ch1->StepperAmplitude=30; ch2->InputMode=NO_INPUT_MODE; ch2->OutputMode=STEP_DIR_MODE; ch2->LimitSwitchOptions=0x0; ch2->BacklashMode=BACKLASH_OFF; ch2->MaxFollowingError=1000000000; //ch2->StepperAmplitude=30; DefineCoordSystem(0,1,2,-1); |
|
| Group: DynoMotion |
Message: 10041 |
From: Jack Gizienski |
Date: 8/26/2014 |
| Subject: Re: Router On/Off [6 Attachments] |
Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, August 26, 2014 7:42 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [6 Attachments] [Attachment(s) from Tom Kerekes included below] Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: // Defines axis 0 and 1 as simple steppers // sets them as an xy coordinate system for GCode //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->LimitSwitchOptions=0x0; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->MaxFollowingError=1000000000; //ch0->StepperAmplitude=30; ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE; ch1->OutputChan0=0;
(Message over 64 KB, truncated) |
|
| Group: DynoMotion |
Message: 10043 |
From: Jack Gizienski |
Date: 8/26/2014 |
| Subject: Re: Router On/Off |
Tom, I tried one other thing. I commented out the last few lines that move the axis inside the limit. In other words I hit the switch, zero the axis and stop. The zero (axis) doesn’t have any impact on the DRO. jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, August 26, 2014 8:39 PM
To: DynoMotion@yahoogroups.com
Subject: RE: [DynoMotion] Router On/Off Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Jack [Attachment(s) from Tom Kerekes included below] Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: // Defines axis 0 and 1 as simple steppers // sets them as an xy coordinate system for GCode //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->LimitSwitchOptions=0x0; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->MaxFollowingError=1000000000; //ch0->StepperAmplitude=30; ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE; |
|
| Group: DynoMotion |
Message: 10044 |
From: Tom Kerekes |
Date: 8/27/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not.
There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is.
Regarding
Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs?
There are many different techniques for running GCode. But usually the GCode is written
with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this:
HTH Regards TK
From: "'Jack Gizienski' jackgiz@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, August 26, 2014 5:39 PM
Subject: RE: [DynoMotion] Router On/Off
Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it
back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, August 26, 2014 7:42 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [6 Attachments] Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you
can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only
one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1,
// direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0)
100.0, // speed to move while searching for index
1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and
Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us
before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and
invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a
G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: // Defines axis 0 and 1 as simple steppers // sets them as an xy coordinate system for GCode //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE; ch0->LimitSwitchOptions=0x0; ch0->BacklashMode=BACKLASH_LINEAR; ch0->BacklashAmount=7.62; ch0->MaxFollowingError=1000000000; //ch0->StepperAmplitude=30; ch1->InputMode=NO_INPUT_MODE; ch1->OutputMode=STEP_DIR_MODE; ch1->LimitSwitchOptions=0x0; //ch1->BacklashMode= BACKLASH_OFF; //ch1->BacklashAmount=18.5;
//ch1->invDistPerCycle=1; //ch1->MaxFollowingError=1000000000; //ch1->StepperAmplitude=30; ch2->InputMode=NO_INPUT_MODE; ch2->OutputMode=STEP_DIR_MODE;<
(Message over 64 KB, truncated) |
|
| Group: DynoMotion |
Message: 10045 |
From: Jack Gizienski |
Date: 8/27/2014 |
| Subject: Re: Router On/Off [10 Attachments] |
Tom, Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Wednesday, August 27, 2014 1:07 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] [Attachment(s) from Tom Kerekes included below] 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below: // Defines axis 0 and 1 as simple steppers // sets them as an xy coordinate system for GCode //SetBitDirection(44,1); // set bit 44 to an output (router motor on/off) //SetBit(44); // set bit to a 1 (which turns router off) //FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 4us ch0->InputMode=NO_INPUT_MODE; ch0->OutputMode=STEP_DIR_MODE;
(Message over 64 KB, truncated)
|
|
| Group: DynoMotion |
Message: 10046 |
From: Tom Kerekes |
Date: 8/27/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero.
G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect.
It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location.
Regards TK
| Group: DynoMotion |
Message: 10054 |
From: Jack Gizienski |
Date: 8/27/2014 |
| Subject: Re: Router On/Off [10 Attachments] |
G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Wednesday, August 27, 2014 3:06 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] [Attachment(s) from Tom Kerekes included below] G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below:
(Message over 64 KB, truncated) |
|
| Group: DynoMotion |
Message: 10055 |
From: Tom Kerekes |
Date: 8/28/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets.
The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence.
After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like :
DoPCFloat(PC_COMM_SET_Z,1.25);
See the KFLOPtoPCCmdExamples.c
To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example:
See the SetFixtureZ.c example.
HTH Regards
From: "'Jack Gizienski' jackgiz@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Wednesday, August 27, 2014 6:54 PM
Subject: RE: [DynoMotion] Router On/Off
G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Wednesday, August 27, 2014 3:06 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try
entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would
show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the
axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any
KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for
1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0)
1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my
X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently,
or on one direction change and not the other, then the result is a drift. That sounds like what you are observing. KFLOP only changes the direction 0.25us before the Step Pulse. But if the drive "steps" on the trailing edge of the pulse instead of the leading edge this can add the pulse length to the setup time. KFLOP defaults to a step pulse length of 32 (~2us). So try setting the Pulse length
to the max setting of 63 (~3.78us) with: FPGA(STEP_PULSE_LENGTH_ADD) =63; // set to max 3.78us Also try inverting the pulse by setting bit 7 with FPGA(STEP_PULSE_LENGTH_ADD) =63 + 0x80; // set to max 3.78us and invert Please see if incuding one of those in your Init C Program solves your problem I have finally figured out my calibration problem, or at least some of it. My Y axis is losing or
gaining steps. If I use a dial indicator and do a G1Y1, G1Y0 I lose about .001. Run it 10 times and I’ve lost .012. If I do a G1Y-1, G1Y0 I gain about .001, run it 10 times and I gain .012. Doesn’t seem to matter if I do a Y1 or a Y6 the result is the same. I tried doing a square, Y2, X1,Y1,X0,Y0 to make sure there wasn’t some kind of timing issue when my axis changed direction, still got the same result. I tried changing the wires to the motor by switching the A and B wires, no change. Double checked the pulses per rev (2000) and current. Everything looks good. If I run the Y out 36” in seems to go out 36” (I have no way of measuring to see if I’m losing .001 at 36”). The X and Z axis are working perfectly they always return to .000. They are Nema 23’s running on a 36 volt supply. The Y is a Nema 34 running on a 60 volt supply. I tried eliminating everything I could in the init program thinking something in the init was causing a problem. No change. See init below:
(Message over 64 KB, truncated)
|
|
| Group: DynoMotion |
Message: 10069 |
From: Jack Gizienski |
Date: 8/30/2014 |
| Subject: Re: Router On/Off [10 Attachments] |
Hi Tom, I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, August 28, 2014 1:15 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] [Attachment(s) from Tom Kerekes included below] Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? |
|
| Group: DynoMotion |
Message: 10079 |
From: Jack Gizienski |
Date: 8/31/2014 |
| Subject: Re: Router On/Off [10 Attachments] |
Tom, Had a chance to down load 433D tonight and would like to use one of the soft limits programs. How would I call one of those programs from my init program or is there a better way to do it? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, August 28, 2014 1:15 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] [Attachment(s) from Tom Kerekes included below] Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? I don't recall that you specified what type of Drives you have or what their timing specs are. But a common problem is to not have enough setup time on the Direction signal before the first Step Pulse occurs. This can result in the first step after a direction change in the wrong direction. If this only happens intermittently, or on one direction change and not the other, then the result is a drift. That sounds like what you are observing.
(Message over 64 KB, truncated)
|
|
| Group: DynoMotion |
Message: 10089 |
From: Tom Kerekes |
Date: 9/1/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
KFLOP now supports soft limit parameters that will automatically trigger a FeedHold whenever the soft limit range is violated. A C program should no longer be required. It usually works best to initialize with infinite soft limit range and then set the soft limit range after homing. As before homing there is no real relationship between
commanded position and the physical limits.
HTH Regards TK
| Group: DynoMotion |
Message: 10090 |
From: Jack Gizienski |
Date: 9/1/2014 |
| Subject: Re: Router On/Off [10 Attachments] |
Thanks Tom, So just add the line SoftLimitPos() or Neg in the SimpleHomeIndexFunctionTest at the end of each axis homing? Are the units of measure pulses? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Monday, September 01, 2014 6:56 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] [Attachment(s) from Tom Kerekes included below] KFLOP now supports soft limit parameters that will automatically trigger a FeedHold whenever the soft limit range is violated. A C program should no longer be required. It usually works best to initialize with infinite soft limit range and then set the soft limit range after homing. As before homing there is no real relationship between commanded position and the physical limits. Had a chance to down load 433D tonight and would like to use one of the soft limits programs. How would I call one of those programs from my init program or is there a better way to do it? Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. |
|
| Group: DynoMotion |
Message: 10092 |
From: Tom Kerekes |
Date: 9/1/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
Yes the units are Step Pulses or encoder counts.
It would be more like:
ch0->SoftLimitPos=100000.0;
ch0->SoftLimitNeg=1000.0;
Regards TK
From: "'Jack Gizienski' jackgiz@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Monday, September 1, 2014 4:15 PM
Subject: RE: [DynoMotion] Router On/Off
Thanks Tom, So just add the line SoftLimitPos() or Neg in the SimpleHomeIndexFunctionTest at the end of each axis homing? Are the units of measure pulses? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Monday, September 01, 2014 6:56 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] KFLOP now supports soft limit parameters that will automatically trigger a FeedHold whenever the soft limit range is violated. A C program should no longer be required. It usually works best to initialize with infinite soft limit range and then set the soft limit range after homing. As before homing there is no real relationship between commanded position and the physical limits. Had a chance to down load 433D tonight and would like to use one of the soft limits programs. How would I call one of those programs from my init program or is there a better way to do it? Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C
Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates
origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding
Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode.
But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing
the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, //
axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0)
100.0, // speed to move while searching for index 1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis)
command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. |
|
| Group: DynoMotion |
Message: 10105 |
From: Tom Kerekes |
Date: 9/2/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
Sorry
we now use a
different technique to store a 64-bit floating point double into a pair
of 32 bit UserData Variables. The "pointer to double" was simpler but
doesn't work if the UserData array is not 64-bit aligned. So there is
now a function called SetUserDataDouble() to do this. See the attached
fixed SetFixtureZ.c
HTH
Regards
TK
From: "'Jack Gizienski' jackgiz@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, September 2, 2014 12:55 PM
Subject: FW: [DynoMotion] Router On/Off
Tom, I got the inputs working. Turned out to be noise from a grounding problem. Also needed to add a series resistor to the inputs to get 100% operation. Can you comment on my second paragraph: I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix
this? Jack From: Jack Gizienski [mailto:jackgiz@...]
Sent: Saturday, August 30, 2014 11:53 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [10
Attachments] Hi Tom, I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits
control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? Jack Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z
in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the
current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home
position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different
techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7,
9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0,
// speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0)
100.0, // speed to move while searching for index
1, // index bit number to watch for (use -1 for none) 0, // index polarity to wait for (1 or 0) 1000); // amount to move inside limits The axis slowly approaches the limit switch, once the
limit switch toggles the axis reverses direction slowly until the switch toggles the other way and then quickly moves inside the limits. I’m assuming that the Zero(axis) command should zero the axis display on the kmotionCNC screen. At least that’s what I would like it to do. Step/Dir Outputs (4-7) are available on KFLOP JP5. You should be able to connect the Gecko to Step/Dir signals there. I’m considering the purchase of a Kstep to improve the performance of my X and Z that use Nema 23’s. My Y axis uses a Nema 34 with a Gecko driver. Is there a simple way to connect the Gecko to the Kstep or Kflop when using a Kstep? |
|
|
|
| Group: DynoMotion |
Message: 10172 |
From: Jack Gizienski |
Date: 9/11/2014 |
| Subject: Re: Router On/Off [2 Attachments] |
Tom, I can’t thank you enough for all of the support and advice you have given me. I started out with zero knowledge on C but by reading some of the suggested tutorials on your website, studying the sample programs and getting support from you, I can now Home my X and Y, Home my Z with each change of the router bit, use softlimits to keep my gantry from rocketing off the table, and have an Estop button when all else fails. Thanks!! I do have one addition question. My Estop is working fine but I seem to remember you suggesting to add a Wait statement in a loop program so as not to overload the CPU. Here’s what I’m doing for my Estop. This is at the end of my Init program: #define ESTOP 4 //define ESTOP bit, low in my case while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high DisableAxis(0); DisableAxis(1); DisableAxis(2); Is this CPU intensive. Do I need to add a wait? From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, September 02, 2014 4:30 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [2 Attachments] [Attachment(s) from Tom Kerekes included below] Sorry we now use a different technique to store a 64-bit floating point double into a pair of 32 bit UserData Variables. The "pointer to double" was simpler but doesn't work if the UserData array is not 64-bit aligned. So there is now a function called SetUserDataDouble() to do this. See the attached fixed SetFixtureZ.c
HTH
Regards
TK
I got the inputs working. Turned out to be noise from a grounding problem. Also needed to add a series resistor to the inputs to get 100% operation. Can you comment on my second paragraph: I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? From: Jack Gizienski [mailto:jackgiz@...]
Sent: Saturday, August 30, 2014 11:53 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [10 Attachments] I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home -1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0) 100.0, // speed to move while searching for index 1, &nbs
(Message over 64 KB, truncated) |
|
| Group: DynoMotion |
Message: 10173 |
From: Tom Kerekes |
Date: 9/11/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
That should be ok. A KFLOP Thread gets the same amount of CPU regardless of what it is doing. See:
But that would be reading the bit hundreds of times per time slice and may be interrupted part way while reading the bit. That should be ok because ReadBit is designed to be pre-emptible. But I prefer to write code that only tests once per time slice and is not interrupted by changing:
while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high
to:
while(ReadBit(ESTOP)!=1) // loop until Estop bit goes high WaitNextTimeSlice();
Regards TK
From: "'Jack Gizienski'
jackgiz@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Thursday, September 11, 2014 7:14 AM
Subject: RE: [DynoMotion] Router On/Off
Tom, I can’t thank you enough for all of the support and advice you have given me. I started out with zero knowledge on C but by reading some of the suggested tutorials on your website, studying the sample programs and getting support from you, I can now Home my X and Y, Home my Z with each change of the router bit, use softlimits to keep my gantry from rocketing off the table, and have an Estop button when all else fails. Thanks!! I do have one addition question. My Estop is working fine but I seem to remember you suggesting to add a Wait statement in a
loop program so as not to overload the CPU. Here’s what I’m doing for my Estop. This is at the end of my Init program: #define ESTOP 4 //define ESTOP bit, low in my case while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high DisableAxis(0); DisableAxis(1); DisableAxis(2); Is this CPU intensive. Do I need to add a wait? From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Tuesday, September 02, 2014 4:30 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [2 Attachments] Sorry we now use a different technique to store a 64-bit floating point double into a pair of 32 bit UserData Variables. The "pointer to double" was simpler but doesn't work if the UserData array is not 64-bit aligned. So there is now a function called
SetUserDataDouble() to do this. See the attached fixed SetFixtureZ.c
HTH
Regards
TK
I got the inputs working. Turned out to be noise from a grounding problem. Also needed to add a series resistor to the inputs to get 100% operation. Can you comment on my second paragraph: I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? From: Jack Gizienski [mailto:jackgiz@...]
Sent: Saturday, August 30, 2014 11:53 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [10 Attachments] I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital
I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix
this? Yes you could do that with a C Program assigned to a User Button. You might want to think
through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c
example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the
coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m
worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing:
Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at
something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a
voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state. Regarding homing I don't exactly follow your description of what is happening but I don't believe you have an encoder Z index Pulse. So set the Index pulse bit number to -1 to indicate to the function you don't have one. The Function is written to zero the position when in the limit switch and then you have program to move inside the switch 1000 steps. So the current machine position will not be zero after the move in 1000 steps. If you wish to re-zero at that point then you can add another Zero() to do so. Additionally the GCode DROs normally display the GCode Program position which is a function of many things such as G92 Offsets, Fixture Offsets, and Tool Offsets. If those not all zero then the DROs will not
necessarily display zero even though the axis is at machine Coordinate Zero. I’ve been working on getting my Homing working. I’m using the SimpleHomeIndexFunctionTest.c. I’ve got 2 problems. First, I’m coming into the Kflop through JP7, pins 7, 9, and 11. For some reason when my Y switch toggles(pin 7), Bits 0 and 1 both toggle. Why is that? Can I change a setting so that only one bit toggles? Same problem with pin 11 but not with pin 9. Second, my machine follows the logic in the SimpleHomeIndexFunction except for setting the axis to zero. Here are the settings I’m using in the test program: result = SimpleHomeIndexFunction(2, // axis number to home 200.0, // speed to move toward home
-1, // direction to move toward home (+1 or -1) 1, // limit bit number to watch for 1, // limit polarity to wait for (1 or 0)
(Message over 64 KB, truncated)
|
|
| Group: DynoMotion |
Message: 10228 |
From: Jack Gizienski |
Date: 10/2/2014 |
| Subject: Re: Router On/Off [10 Attachments] |
Hi Tom, I’ve been playing with my Estop and thought I’d add a line to stop my router if the Estop was pressed. Here’s what I did but it doesn’t work. Everything else works fine: while(ReadBit(ESTOP)!=1) // loop until Limit bit goes to specified polarity WaitNextTimeSlice(); DisableAxis(0); //Stop X DisableAxis(1); //Stop Y SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage return 0; I use bit 44 to start and stop the router with M3 and M5 commands. M5 sets bit 44 to 1 to stop the router. What am I missing? Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, September 11, 2014 10:33 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] [Attachment(s) from Tom Kerekes included below] That should be ok. A KFLOP Thread gets the same amount of CPU regardless of what it is doing. See: But that would be reading the bit hundreds of times per time slice and may be interrupted part way while reading the bit. That should be ok because ReadBit is designed to be pre-emptible. But I prefer to write code that only tests once per time slice and is not interrupted by changing: while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high while(ReadBit(ESTOP)!=1) // loop until Estop bit goes high I can’t thank you enough for all of the support and advice you have given me. I started out with zero knowledge on C but by reading some of the suggested tutorials on your website, studying the sample programs and getting support from you, I can now Home my X and Y, Home my Z with each change of the router bit, use softlimits to keep my gantry from rocketing off the table, and have an Estop button when all else fails. Thanks!! I do have one addition question. My Estop is working fine but I seem to remember you suggesting to add a Wait statement in a loop program so as not to overload the CPU. Here’s what I’m doing for my Estop. This is at the end of my Init program: #define ESTOP 4 //define ESTOP bit, low in my case while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high Is this CPU intensive. Do I need to add a wait? Sorry we now use a different technique to store a 64-bit floating point double into a pair of 32 bit UserData Variables. The "pointer to double" was simpler but doesn't work if the UserData array is not 64-bit aligned. So there is now a function called SetUserDataDouble() to do this. See the attached fixed SetFixtureZ.c
HTH
Regards
TK I got the inputs working. Turned out to be noise from a grounding problem. Also needed to add a series resistor to the inputs to get 100% operation. Can you comment on my second paragraph: I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? From: Jack Gizienski [mailto:jackgiz@...]
Sent: Saturday, August 30, 2014 11:53 PM
To: 'DynoMotion@yahoogroups.com'
Subject: RE: [DynoMotion] Router On/Off [10 Attachments] I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: Tom, Thanks for the quick response. The inputs are being driven to 3.81-3.83 volts so I think I’m safe. If you think this is too high I could add a voltage divider to lower the voltage down to say 3 volts. The unused inputs are floating so I’ll tie them low to see if that helps. You’re right, I don’t have an encoder. The Zero(axis) didn’t seem to be working so I put the limit switch bit in the indexbit position and it seemed to work by reversing direction. I thought it was a little strange to set zero when I came off the limit switch. I’ll set it back to -1. That still leaves the issue concerning zeroing the axis. I’ve zeroed the axis manually several inches off the limit switch and then ran the homing program and there didn’t seem to be any change to the axis DRO. I’m not currently using any offsets that I am aware of. I was manually eyeballing the router bit position and pushing the axis zero on the DRO to home a part. If the DRO isn’t at zero won’t I have a problem when I start my Gcode? Please do not drive any KFLOP input above 3.85V. If you do clamping current may leak to an adjacent pin. See: Also If an unused input is not connected to anything it may float high or low in a random manner or be likely to follow the voltage level of an adjacent pin. This is of no consequence. When using KFLOP inputs they are voltage sensitive, not current sensitive, so they must be driven high and low. You can not just leave them open and assume they will be in a particular state.
(Message over 64 KB, truncated)
|
|
| Group: DynoMotion |
Message: 10231 |
From: Moray Cuthill |
Date: 10/2/2014 |
| Subject: Re: Router On/Off |
Jack, If you have more than one line of code after a conditional statement (i.e. While/If), then you need to use curly brackets to contain the lines of code, otherwise only the line immediately after the conditional statement gets treated as part of the conditional test. So in the case of your While loop, only the WaitNextTimeSlice() gets looped. Everything after gets ignored, until the Which loop has been exitted. So what your code should be is- while(ReadBit(ESTOP)!=1) {// loop until Limit bit goes to specified polarity WaitNextTimeSlice(); DisableAxis(0); //Stop X DisableAxis(1); //Stop Y SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage } return 0; Moray |
|
| Group: DynoMotion |
Message: 10232 |
From: Jack Gizienski |
Date: 10/2/2014 |
| Subject: Re: Router On/Off |
Thanks Moray. Seems like I read that somewhere but forgot. I’ll give it a try to see how it works. Funny everything else seemed to work correctly but that one line. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, October 02, 2014 6:05 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off If you have more than one line of code after a conditional statement (i.e. While/If), then you need to use curly brackets to contain the lines of code, otherwise only the line immediately after the conditional statement gets treated as part of the conditional test. So in the case of your While loop, only the WaitNextTimeSlice() gets looped. Everything after gets ignored, until the Which loop has been exitted. So what your code should be is- while(ReadBit(ESTOP)!=1) {// loop until Limit bit goes to specified polarity WaitNextTimeSlice(); DisableAxis(0); //Stop X DisableAxis(1); //Stop Y SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage } return 0; On Thu, Oct 2, 2014 at 4:55 PM, 'Jack Gizienski' jackgiz@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote: Hi Tom, I’ve been playing with my Estop and thought I’d add a line to stop my router if the Estop was pressed. Here’s what I did but it doesn’t work. Everything else works fine: while(ReadBit(ESTOP)!=1) // loop until Limit bit goes to specified polarity WaitNextTimeSlice(); DisableAxis(0); //Stop X DisableAxis(1); //Stop Y SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage return 0; I use bit 44 to start and stop the router with M3 and M5 commands. M5 sets bit 44 to 1 to stop the router. What am I missing? Jack [Attachment(s) from Tom Kerekes included below] That should be ok. A KFLOP Thread gets the same amount of CPU regardless of what it is doing. See: But that would be reading the bit hundreds of times per time slice and may be interrupted part way while reading the bit. That should be ok because ReadBit is designed to be pre-emptible. But I prefer to write code that only tests once per time slice and is not interrupted by changing: while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high while(ReadBit(ESTOP)!=1) // loop until Estop bit goes high I can’t thank you enough for all of the support and advice you have given me. I started out with zero knowledge on C but by reading some of the suggested tutorials on your website, studying the sample programs and getting support from you, I can now Home my X and Y, Home my Z with each change of the router bit, use softlimits to keep my gantry from rocketing off the table, and have an Estop button when all else fails. Thanks!! I do have one addition question. My Estop is working fine but I seem to remember you suggesting to add a Wait statement in a loop program so as not to overload the CPU. Here’s what I’m doing for my Estop. This is at the end of my Init program: #define ESTOP 4 //define ESTOP bit, low in my case while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high Is this CPU intensive. Do I need to add a wait? Sorry we now use a different technique to store a 64-bit floating point double into a pair of 32 bit UserData Variables. The "pointer to double" was simpler but doesn't work if the UserData array is not 64-bit aligned. So there is now a function called SetUserDataDouble() to do this. See the attached fixed SetFixtureZ.c
HTH
Regards
TK I got the inputs working. Turned out to be noise from a grounding problem. Also needed to add a series resistor to the inputs to get 100% operation. Can you comment on my second paragraph: I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location. Yes, the coordinates on the Axis screen reflect the true position of the gantry. The KmotionCNC DRO’s do change when the different axis move and they remain green. I’m starting to understand what needs to be done. At the end of each axis homing I’m sending the X and Y to the home position of my fixture. The axis screen agrees with the steps that I have programmed. I tried a G93 and a G54 (which I had set to 2,2,2) to see if it would have any impact on the DRO but the DRO didn’t change. Maybe I’m worried about nothing but I was thinking the DRO needed to read 0,0,0 before I started my Gcode program. 3.83 would be safe but may still cause some small clamping currents. 3.3V or lower would not. There is no need to tie unused inputs low. If they are not used it doesn't matter what their state is. Regarding Zeroing: Zero() should make the Destination on the KMotion Axis Screen for the specified axis 0. This corresponds to "Machine Coordinates - but in counts or steps. Does it? You might also try entering the Zero command on the Console Screen. When the Axis moves does the KMotionCNC DROs even change? What color are the KMotionCNC DROs? There are many different techniques for running GCode. But usually the GCode is written with the origin being at something like the bottom left hand corner of the stock. So before running the GCode the Operator would move there and then "Zero" the G Code Program Coordinates by pushing the "Zero" button on the KMotionCNC Screen. This would create a GCode Offset such that the DROs when displaying program coordinates would show zero. You might also read this: |
|
| Group: DynoMotion |
Message: 10234 |
From: Tom Kerekes |
Date: 10/2/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
Was your intent to loop waiting for the ESTOP bit to go high and then continue on doing the other stuff including the SetBit(44) ?
If so, then I think your original code was correct and I'm not sure why it didn't work.
It would help if you indented your code more carefully to indicate what lines of code you expected to be within the while loop. I know that email sometimes messes up Tabs. It is usually better to use spaces. Or attach the file as an attachement.
If you attache the entire program we can look it over.
Regards TK
| Group: DynoMotion |
Message: 10235 |
From: Jack Gizienski |
Date: 10/2/2014 |
| Subject: Re: Router On/Off |
Hi Tom, You are correct. I wanted the Estop “While” to loop until the bit went high and then continue. Attached is the whole Init file. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, October 02, 2014 9:53 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off Was your intent to loop waiting for the ESTOP bit to go high and then continue on doing the other stuff including the SetBit(44) ? If so, then I think your original code was correct and I'm not sure why it didn't work. It would help if you indented your code more carefully to indicate what lines of code you expected to be within the while loop. I know that email sometimes messes up Tabs. It is usually better to use spaces. Or attach the file as an attachement. If you attache the entire program we can look it over. Thanks Moray. Seems like I read that somewhere but forgot. I’ll give it a try to see how it works. Funny everything else seemed to work correctly but that one line. If you have more than one line of code after a conditional statement (i.e. While/If), then you need to use curly brackets to contain the lines of code, otherwise only the line immediately after the conditional statement gets treated as part of the conditional test. So in the case of your While loop, only the WaitNextTimeSlice() gets looped. Everything after gets ignored, until the Which loop has been exitted. So what your code should be is- while(ReadBit(ESTOP)!=1) {// loop until Limit bit goes to specified polarity SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage I’ve been playing with my Estop and thought I’d add a line to stop my router if the Estop was pressed. Here’s what I did but it doesn’t work. Everything else works fine: while(ReadBit(ESTOP)!=1) // loop until Limit bit goes to specified polarity SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage I use bit 44 to start and stop the router with M3 and M5 commands. M5 sets bit 44 to 1 to stop the router. That should be ok. A KFLOP Thread gets the same amount of CPU regardless of what it is doing. See: But that would be reading the bit hundreds of times per time slice and may be interrupted part way while reading the bit. That should be ok because ReadBit is designed to be pre-emptible. But I prefer to write code that only tests once per time slice and is not interrupted by changing: while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high while(ReadBit(ESTOP)!=1) // loop until Estop bit goes high I can’t thank you enough for all of the support and advice you have given me. I started out with zero knowledge on C but by reading some of the suggested tutorials on your website, studying the sample programs and getting support from you, I can now Home my X and Y, Home my Z with each change of the router bit, use softlimits to keep my gantry from rocketing off the table, and have an Estop button when all else fails. Thanks!! I do have one addition question. My Estop is working fine but I seem to remember you suggesting to add a Wait statement in a loop program so as not to overload the CPU. Here’s what I’m doing for my Estop. This is at the end of my Init program: #define ESTOP 4 //define ESTOP bit, low in my case while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high Is this CPU intensive. Do I need to add a wait? Sorry we now use a different technique to store a 64-bit floating point double into a pair of 32 bit UserData Variables. The "pointer to double" was simpler but doesn't work if the UserData array is not 64-bit aligned. So there is now a function called SetUserDataDouble() to do this. See the attached fixed SetFixtureZ.c
HTH
Regards
TK I got the inputs working. Turned out to be noise from a grounding problem. Also needed to add a series resistor to the inputs to get 100% operation. Can you comment on my second paragraph: I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. G92 worked much better than G93. Amazing what one little number can do. I thinking that I could modify your function so that my Z would come down on a ¼” block of Aluminum to close a circuit to stop motion, then do a g92 and then back off to a safe distance. Is there a way to code a G92 X,Y,Z in C so that everything is automatic? G93 relates to inverse time mode. Was that a typo? G92X0Y0Z0 should calculate a G92 offset to make the current position Zero. G54 should select the first Fixture offset. By default the first fixture offset is already selected so selecting it again will have no effect. It is obviously important to set the coordinates origin before running GCode or the code will cut at an arbitrary location.
From:
(Message over 64 KB, truncated) |
|
|
|
| Group: DynoMotion |
Message: 10236 |
From: Tom Kerekes |
Date: 10/2/2014 |
| Subject: Re: Router On/Off [1 Attachment] |
Hi Jack,
It looks correct to me. How are you testing? What happens exactly? Check if the Axes disable on the Axis Screen. Check if IO 44 goes High on the Digital I Screen. Maybe add a print statement before the SetBit function call like:
printf("Setting bit 44\n");
Regards TK
| Group: DynoMotion |
Message: 10240 |
From: Jack Gizienski |
Date: 10/3/2014 |
| Subject: Re: Router On/Off |
Hi Tom, I always save 2 copies of my C programs, one in my local C drive and one on my network drive once I have the program debugged and working. As it turns out I was editing my network copy but KmotionCNC was looking at the C drive copy. Once I straightened that out the program works fine. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Friday, October 03, 2014 12:24 AM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off It looks correct to me. How are you testing? What happens exactly? Check if the Axes disable on the Axis Screen. Check if IO 44 goes High on the Digital I Screen. Maybe add a print statement before the SetBit function call like: printf("Setting bit 44\n"); [Attachment(s) from Jack Gizienski included below] You are correct. I wanted the Estop “While” to loop until the bit went high and then continue. Attached is the whole Init file. Was your intent to loop waiting for the ESTOP bit to go high and then continue on doing the other stuff including the SetBit(44) ? If so, then I think your original code was correct and I'm not sure why it didn't work. It would help if you indented your code more carefully to indicate what lines of code you expected to be within the while loop. I know that email sometimes messes up Tabs. It is usually better to use spaces. Or attach the file as an attachement. If you attache the entire program we can look it over. Thanks Moray. Seems like I read that somewhere but forgot. I’ll give it a try to see how it works. Funny everything else seemed to work correctly but that one line. If you have more than one line of code after a conditional statement (i.e. While/If), then you need to use curly brackets to contain the lines of code, otherwise only the line immediately after the conditional statement gets treated as part of the conditional test. So in the case of your While loop, only the WaitNextTimeSlice() gets looped. Everything after gets ignored, until the Which loop has been exitted. So what your code should be is- while(ReadBit(ESTOP)!=1) {// loop until Limit bit goes to specified polarity SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage I’ve been playing with my Estop and thought I’d add a line to stop my router if the Estop was pressed. Here’s what I did but it doesn’t work. Everything else works fine: while(ReadBit(ESTOP)!=1) // loop until Limit bit goes to specified polarity SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage I use bit 44 to start and stop the router with M3 and M5 commands. M5 sets bit 44 to 1 to stop the router. That should be ok. A KFLOP Thread gets the same amount of CPU regardless of what it is doing. See: But that would be reading the bit hundreds of times per time slice and may be interrupted part way while reading the bit. That should be ok because ReadBit is designed to be pre-emptible. But I prefer to write code that only tests once per time slice and is not interrupted by changing: while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high while(ReadBit(ESTOP)!=1) // loop until Estop bit goes high I can’t thank you enough for all of the support and advice you have given me. I started out with zero knowledge on C but by reading some of the suggested tutorials on your website, studying the sample programs and getting support from you, I can now Home my X and Y, Home my Z with each change of the router bit, use softlimits to keep my gantry from rocketing off the table, and have an Estop button when all else fails. Thanks!! I do have one addition question. My Estop is working fine but I seem to remember you suggesting to add a Wait statement in a loop program so as not to overload the CPU. Here’s what I’m doing for my Estop. This is at the end of my Init program: #define ESTOP 4 //define ESTOP bit, low in my case while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high Is this CPU intensive. Do I need to add a wait? Sorry we now use a different technique to store a 64-bit floating point double into a pair of 32 bit UserData Variables. The "pointer to double" was simpler but doesn't work if the UserData array is not 64-bit aligned. So there is now a function called SetUserDataDouble() to do this. See the attached fixed SetFixtureZ.c
HTH
Regards
TK I got the inputs working. Turned out to be noise from a grounding problem. Also needed to add a series resistor to the inputs to get 100% operation. Can you comment on my second paragraph: I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. |
|
| Group: DynoMotion |
Message: 10322 |
From: Jack Gizienski |
Date: 10/12/2014 |
| Subject: Re: Router On/Off |
Hi Tom, I got my Kstep the other day and am preparing to install it. However, before I do I want to confirm that I understand the wiring correctly. I will be using external limit switches for calibrating, Estop etc and an external relay to turn the router on and off. I assume that it is good practice to use an isolated supply for the external functions so here’s my plan: Power supply 1 +5 Volt Power the Kflop through JR1, pins 3 and 4 (does this also power the Kstep through JP 36?) Power supply 2 – Ground not tied to PS1 ground or +5 V +5 and +12 Volt +5 powers the Kstep through J6 Grd and +5V +5 also goes to JP33 pins 1 since my relay for the router is 5 volt (or do I need to switch to 12 v?) +12 goes the Kstep JP33 pin 8 and the ground to one side of all the input switches Remove the “disable Opto” jumper Remove JP34 and JP35 Isolation jumpers Power supply 3 +36 Volts (ground is not connected to PS1 or PS2) +36 goes to J1 VB and the GND to GND 1 Jumper on position A of Voltage Clamp Tag on the steppers says 3 Amps so do I put the current jumper on “H” for 3.13 Amps or do I derate to 2.5 Amps with jumpers on “M” and “L”? I have one Nema 34 for my Y running off a Gecko so I am planning on connecting the Gecko input to JP26 pins 3 and 4 and the Kflop +5 V. I also know that I have to set bit 45 and do a KstepPresent=True and add 8 to the output channel numbers for X, Y and Z. Does this look right and have I missed anything? I really want to avoid letting the smoke out of any of the components. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, October 02, 2014 9:53 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off Was your intent to loop waiting for the ESTOP bit to go high and then continue on doing the other stuff including the SetBit(44) ? If so, then I think your original code was correct and I'm not sure why it didn't work. It would help if you indented your code more carefully to indicate what lines of code you expected to be within the while loop. I know that email sometimes messes up Tabs. It is usually better to use spaces. Or attach the file as an attachement. If you attache the entire program we can look it over. Thanks Moray. Seems like I read that somewhere but forgot. I’ll give it a try to see how it works. Funny everything else seemed to work correctly but that one line. If you have more than one line of code after a conditional statement (i.e. While/If), then you need to use curly brackets to contain the lines of code, otherwise only the line immediately after the conditional statement gets treated as part of the conditional test. So in the case of your While loop, only the WaitNextTimeSlice() gets looped. Everything after gets ignored, until the Which loop has been exitted. So what your code should be is- while(ReadBit(ESTOP)!=1) {// loop until Limit bit goes to specified polarity SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage I’ve been playing with my Estop and thought I’d add a line to stop my router if the Estop was pressed. Here’s what I did but it doesn’t work. Everything else works fine: while(ReadBit(ESTOP)!=1) // loop until Limit bit goes to specified polarity SetBit(44); // set bit to a 1 (which turns router off) Move (2,-3000); // raise bit to just under soft limit DisableAxis(2); // Stop Z and survey the damage I use bit 44 to start and stop the router with M3 and M5 commands. M5 sets bit 44 to 1 to stop the router. That should be ok. A KFLOP Thread gets the same amount of CPU regardless of what it is doing. See: But that would be reading the bit hundreds of times per time slice and may be interrupted part way while reading the bit. That should be ok because ReadBit is designed to be pre-emptible. But I prefer to write code that only tests once per time slice and is not interrupted by changing: while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high while(ReadBit(ESTOP)!=1) // loop until Estop bit goes high I can’t thank you enough for all of the support and advice you have given me. I started out with zero knowledge on C but by reading some of the suggested tutorials on your website, studying the sample programs and getting support from you, I can now Home my X and Y, Home my Z with each change of the router bit, use softlimits to keep my gantry from rocketing off the table, and have an Estop button when all else fails. Thanks!! I do have one addition question. My Estop is working fine but I seem to remember you suggesting to add a Wait statement in a loop program so as not to overload the CPU. Here’s what I’m doing for my Estop. This is at the end of my Init program: #define ESTOP 4 //define ESTOP bit, low in my case while(ReadBit(ESTOP)!=1); // loop until Estop bit goes high Is this CPU intensive. Do I need to add a wait? Sorry we now use a different technique to store a 64-bit floating point double into a pair of 32 bit UserData Variables. The "pointer to double" was simpler but doesn't work if the UserData array is not 64-bit aligned. So there is now a function called SetUserDataDouble() to do this. See the attached fixed SetFixtureZ.c
HTH
Regards
TK I got the inputs working. Turned out to be noise from a grounding problem. Also needed to add a series resistor to the inputs to get 100% operation. Can you comment on my second paragraph: I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? I had everything working pretty well the other day but everything was hooked up temporarily so I ripped it all apart and installed everything permanently. Of course now nothing works. I have my X switch on pin 7, bit 0, Y on pin 8, bit 1 and Z on pin 9, bit 2. When I toggle the switches I can see the state change on bit 0, 1, and 2 on the digital I/O screen. When I run the SimpleHOmeIndexFunctionTest.c program I believe it is ignoring the move toward the switch and immediately moves toward the inside limits. I tried changing the limit bit polarity with no change. I’m thinking I have my bits and I/O’s mixed up. Is there a table somewhere that shows which bits control which I/O’s? I have the Z homing kind of working using pieces of the SinpleHomeIndexFunction. If I try to use the SetFixtureZ.c program I get a compiler error on line: pD[TMP]=NewOriginOffset;. It doesn’t like the pD. It says pD is undeclared. How do I fix this? Yes you could do that with a C Program assigned to a User Button. You might want to think through exactly how you want to do things first. There are several ways to set the origin including G92 offsets, Fixture Offsets, and Tool Offsets. The first step would be to write the C Program to move until the input is detected and then back off. This is basically the same as a Home sequence. After that works you can add a KFLOP to KMotionCNC command to set the Z axis. Using somthing like : DoPCFloat(PC_COMM_SET_Z,1.25); See the KFLOPtoPCCmdExamples.c To make things simpler the necessary helper functions can be accessed by simply including KFLOPtoPCCmdExamples.c as shown in the example: See the SetFixtureZ.c example. |
|
| Group: DynoMotion |
Message: 10323 |
From: Tom Kerekes |
Date: 10/12/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
See below:
| Group: DynoMotion |
Message: 10327 |
From: Jack Gizienski |
Date: 10/13/2014 |
| Subject: Re: Router On/Off [10 Attachments] |
Hi Tom, In Ref to using the Gecko for my Y axis on JP5, pins 1 & 2. It’s a 201X by the way. Do I simply modify the Init to the following? ch1->OutputChan0=4; Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Sunday, October 12, 2014 9:35 PM
To: DynoMotion@yahoogroups.com
Cc: Brad Geving
Subject: Re: [DynoMotion] Router On/Off [10 Attachments] [Attachment(s) from Tom Kerekes included below] I got my Kstep the other day and am preparing to install it. However, before I do I want to confirm that I understand the wiring correctly. I will be using external limit switches for calibrating, Estop etc and an external relay to turn the router on and off. I assume that it is good practice to use an isolated supply for the external functions so here’s my plan: Power the Kflop through JR1, pins 3 and 4 (does this also power the Kstep through JP 36?) >>> It can but not if you wish to run in fully isolated mode. Removing the Isolation Jumpers breaks this connection so your method below is required to supply +5V to KFLOP. Power supply 2 – Ground not tied to PS1 ground or +5 V +5 powers the Kstep through J6 Grd and +5V +5 also goes to JP33 pins 1 since my relay for the router is 5 volt (or do I need to switch to 12 v?) >>> That should work, but there is ~ 1V drop across the relay driver so the load will only see 4V +12 goes the Kstep JP33 pin 8 and the ground to one side of all the input switches Remove the “disable Opto” jumper Remove JP34 and JP35 Isolation jumpers +36 Volts (ground is not connected to PS1 or PS2) +36 goes to J1 VB and the GND to GND 1 Jumper on position A of Voltage Clamp Tag on the steppers says 3 Amps so do I put the current jumper on “H” for 3.13 Amps or do I derate to 2.5 Amps with jumpers on “M” and “L”? >>> The 2.5A setting should be used to avoid running the motors too hot\ I have one Nema 34 for my Y running off a Gecko so I am planning on connecting the Gecko input to JP26 pins 3 and 4 and the Kflop +5 V. >>> No I don't think this is correct. Normally the Gecko would be connected to KFLOP JP5 pins 1 and 2 (Step Dir Generator #4). It depends which type of gecko you have. I also know that I have to set bit 45 and do a KstepPresent=True and add 8 to the output channel numbers for X, Y and Z. Does this look right and have I missed anything? I really want to avoid letting the smoke out of any of the components. |
|
| Group: DynoMotion |
Message: 10360 |
From: Tom Kerekes |
Date: 10/21/2014 |
| Subject: Re: Router On/Off |
Hi Jack,
Probably. But it depends on the specifications of the device you are connecting it to. In that configuration the Relay Output will sink a signal up to 30V @ to 100ma to a low level of 1V or less.
HTH Regards TK
| Group: DynoMotion |
Message: 10364 |
From: Jack Gizienski |
Date: 10/22/2014 |
| Subject: Re: Router On/Off |
Hi Tom, Only driving the front end of an opto so that should be well within the relay output limits. Thanks. Jack From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Wednesday, October 22, 2014 1:52 AM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Router On/Off Probably. But it depends on the specifications of the device you are connecting it to. In that configuration the Relay Output will sink a signal up to 30V @ to 100ma to a low level of 1V or less. Tried to cut a part tonight and the router wouldn't fire up. I hadn't tried to use the router since switching to the Kstep. The relay card I'm using is looking for a low. Can I connect pin 2 to grd and the relay wire to pin 1 of JP33? In Ref to using the Gecko for my Y axis on JP5, pins 1 & 2. It’s a 201X by the way. Do I simply modify the Init to the following? I got my Kstep the other day and am preparing to install it. However, before I do I want to confirm that I understand the wiring correctly. I will be using external limit switches for calibrating, Estop etc and an external relay to turn the router on and off. I assume that it is good practice to use an isolated supply for the external functions so here’s my plan: Power the Kflop through JR1, pins 3 and 4 (does this also power the Kstep through JP 36?) >>> It can but not if you wish to run in fully isolated mode. Removing the Isolation Jumpers breaks this connection so your method below is required to supply +5V to KFLOP. Power supply 2 – Ground not tied to PS1 ground or +5 V +5 powers the Kstep through J6 Grd and +5V +5 also goes to JP33 pins 1 since my relay for the router is 5 volt (or do I need to switch to 12 v?) >>> That should work, but there is ~ 1V drop across the relay driver so the load will only see 4V +12 goes the Kstep JP33 pin 8 and the ground to one side of all the input switches Remove the “disable Opto” jumper Remove JP34 and JP35 Isolation jumpers +36 Volts (ground is not connected to PS1 or PS2) +36 goes to J1 VB and the GND to GND 1 Jumper on position A of Voltage Clamp Tag on the steppers says 3 Amps so do I put the current jumper on “H” for 3.13 Amps or do I derate to 2.5 Amps with jumpers on “M” and “L”? >>> The 2.5A setting should be used to avoid running the motors too hot\ I have one Nema 34 for my Y running off a Gecko so I am planning on connecting the Gecko input to JP26 pins 3 and 4 and the Kflop +5 V. >>> No I don't think this is correct. Normally the Gecko would be connected to KFLOP JP5 pins 1 and 2 (Step Dir Generator #4). It depends which type of gecko you have. I also know that I have to set bit 45 and do a KstepPresent=True and add 8 to the output channel numbers for X, Y and Z. Does this look right and have I missed anything? I really want to avoid letting the smoke out of any of the components. |
|
| | | | | | | | | | | | | | | | | | | | | | | |
